Skip to main content

客服 AI Agent 全链路技术方案

1. 方案概述​

1.1 核心目标​

  • 高并发支撑：实现用户咨询的智能意图识别与任务调度，支撑 BC 端客服系统高并发场景
  • 成本优化：通过 Workflow 引擎固化标准化流程，降低 LLM 调用成本
  • 闭环优化：构建用户反馈自动化收集-分析-优化闭环，持续提升识别准确率与用户体验
  • 可治理与可演进：形成模型、规则、流程、数据的协同治理机制，支持持续迭代与效果评估

1.2 技术栈选型​

模块技术选型选型理由
核心框架Spring Boot 3.x适配 Java 后端技术栈，支持高并发与分布式部署
意图识别微调 Llama3 + 规则引擎兼顾长尾意图识别能力与高频意图匹配效率
固定流程引擎Flowable 7.x轻量可嵌入，支持 BPMN2.0 规范，适配 Java 生态
会话存储Redis Cluster高并发读写支持，适配会话上下文临时存储场景
反馈分析Flink + ClickHouse实时处理用户行为流，支持离线分析与指标统计
前端交互React + Ant Design适配客服系统前端技术栈，支持反馈组件集成

补充说明：

  • 模型侧：支持 Llama3/GLM 等主流模型的 LoRA/全量微调，模型服务可独立部署以支撑弹性扩缩
  • 数据侧：ClickHouse 用于长周期指标沉淀，Flink 用于实时异常发现与负样本挖掘
  • 流程侧：Workflow 作为“确定性路径”，与 LLM 的“概率性路径”形成分层协同

2. 核心架构设计​

2.1 整体架构图​

2.2 核心数据流​

  • 用户咨询流：前端 → API网关 → Agent核心服务 → 意图识别/固定流程 → BC端系统 → 前端
  • 反馈数据流：前端 → 反馈服务 → Flink实时处理 → ClickHouse存储 → 监控/模型优化

补充说明：

  • 用户咨询流侧重低时延与高可用，优先走固定流程或高置信度路径
  • 反馈数据流侧重可追溯与可学习，强调“数据-评测-优化”闭环的自动化

3. 核心模块技术实现​

3.1 意图识别模块​

3.1.1 用户意图识别怎么做？​

  • 核心方案
    • 基础层：客服领域微调大模型（如 Llama3/GLM 微调客服语料）+ 规则匹配 + 关键词字典（覆盖高频意图，如“查订单”“开发票”）
    • 增强层：引入客服意图知识图谱（关联“意图-实体-场景”，如“开发票”关联“订单 ID”“发票类型”）
  • 流程：先规则匹配高频意图，匹配失败再调用大模型识别
  • 工程化要点
    • 多级缓存：高频意图与实体词典本地缓存，降低网络与模型调用压力
    • 实体校验：意图识别后对关键实体进行完整性检查，避免错误触发流程
    • 可配置策略：规则优先级、阈值、兜底逻辑由配置中心统一管理

3.1.2 意图识别如何评测？​

  • 核心指标
    • 精准度：识别正确的占比（如“查订单”被识别为“查订单”的比例）
    • 召回率：真实意图中被识别到的比例
    • 置信度分布：识别结果的置信度阈值（如设定 0.8 为合格线）
  • 评测方法
    • 离线：构造客服意图测试集（覆盖高频/长尾意图），计算精准度/召回率
    • 在线：AB 测试 + 人工抽样复核，统计实际场景识别准确率
  • 评测要点
    • 样本分层：区分高频/长尾/新业务场景，避免指标被高频意图“稀释”
    • 回放验证：历史真实对话回放，验证新策略对实际业务的收益

3.1.3 识别错了用户意图怎么办？​

  • 容错流程
    • 置信度低于阈值（如 0.8）：触发意图澄清（如“请问你是想查询订单还是开发票？”）
    • 澄清后仍不明确：转人工客服
    • 错误案例沉淀：将识别错误的意图加入负样本库，用于大模型迭代微调
  • 保障策略
    • 兜底提示：提供清晰的澄清选项与示例，降低用户重复输入成本
    • 人工联动：转人工时保留意图候选与上下文，提升人工处理效率

3.1.4 固定流程用 Workflow 替代 LLM？​

  • 适用场景：如“发票 PDF 识别”“订单状态查询”等步骤固定、输入输出明确的流程
  • 实现方式
    • Workflow 引擎：用低代码 Workflow 引擎（如 Flowable/Activiti）定义固定流程（如“上传 PDF → 调用 OCR → 提取发票信息 → 返回结果”）
    • 规则路由：在 Agent 中增加规则路由，命中固定流程关键词（如“开发票 PDF”）时直接触发 Workflow，跳过 LLM 识别
  • 收益说明
    • 可解释性强：流程可视化与可审计，适合需要合规与可控的业务
    • 成本可控：绕开大模型推理，显著降低请求成本与时延

3.2 固定流程模块（Workflow）​

3.2.1 流程定义规范​

  • 流程定义：基于 BPMN2.0，通过 Flowable Modeler 可视化配置
  • 核心流程示例（发票 PDF 识别）：
<process id="invoicePdfRecognition" name="发票PDF识别流程" isExecutable="true">
  <startEvent id="start" />
  <serviceTask id="ocrTask" name="PDF-OCR识别"
               implementation="com.kefu.agent.workflow.service.OcrServiceTask" />
  <serviceTask id="extractTask" name="发票信息提取"
               implementation="com.kefu.agent.workflow.service.InvoiceExtractServiceTask" />
  <serviceTask id="verifyTask" name="信息校验"
               implementation="com.kefu.agent.workflow.service.InvoiceVerifyServiceTask" />
  <endEvent id="end" />
  <sequenceFlow id="flow1" sourceRef="start" targetRef="ocrTask" />
  <sequenceFlow id="flow2" sourceRef="ocrTask" targetRef="extractTask" />
  <sequenceFlow id="flow3" sourceRef="extractTask" targetRef="verifyTask" />
  <sequenceFlow id="flow4" sourceRef="verifyTask" targetRef="end" />
</process>

3.2.2 流程路由机制​

  • 路由规则：基于用户 query 关键词 + 业务场景双匹配
  • 实现方式
    • 关键词索引：采用 Elasticsearch 构建固定流程关键词索引
    • 路由优先级：固定流程路由 > 意图识别路由
    • 匹配阈值：关键词匹配度 ≥0.9 触发固定流程
  • 治理策略
    • 灰度发布：新增流程先灰度放量，验证转化率与完成率
    • 回退机制：流程异常时自动回退到意图识别路径

3.3 用户反馈闭环模块​

3.3.1 反馈数据采集​

采集维度与埋点设计

反馈类型埋点事件名采集字段上报时机
二次提问user_second_queryuserId, sessionId, firstReplyId, query用户发起二次提问时
点赞/点踩user_feedback_likeuserId, sessionId, replyId, feedbackType用户点击点赞/点踩按钮时
离开user_leaveuserId, sessionId, stayDuration, step用户关闭会话窗口时
人工转接user_transfer_humanuserId, sessionId, transferReason触发人工转接时

上报方式

  • 实时上报：通过 WebSocket 推送用户行为事件
  • 批量兜底：前端本地缓存 10s，异常时批量重试上报
  • 数据质量校验：校验 sessionId、userId、一致性与重复上报，保证数据可用性

3.3.2 反馈分析与优化闭环​

实时分析 - Flink Job

  • 架构设计
    • 数据入口：前端行为事件与意图识别结果统一进入消息队列（如 Kafka），按 sessionId 进行分区
    • 计算层：Flink 以 sessionId 作为 key 进行双流关联，实时判定意图识别是否可能错误
    • 状态管理：采用 Flink state 保存短期会话上下文与意图结果，配置 TTL 限制内存占用
    • 落地层：异常/负样本事件写入 ClickHouse，指标类数据同步写入监控系统
  • 方案设计
    • 触发规则：二次提问/点踩/转人工等事件触发“潜在错误意图”判定
    • 关联策略：按 sessionId 聚合，结合时间窗口（如 30 分钟）判断因果关系
    • 分级输出：高置信错误进入负样本库；中低置信进入人工复核队列
    • 闭环联动：负样本用于模型微调，规则命中失败样本用于关键词字典扩展

优化落地

  • 模型优化：每日凌晨将 ClickHouse 中的 intent_error_event 数据导出为负样本，用于 LLM 微调（微调周期：每周 1 次）
  • 规则优化：每周统计高频错误意图，更新规则引擎的关键词字典与匹配权重
  • 流程优化：基于固定流程的完成率耗时指标，优化 Flowable 流程节点的超时配置与重试策略
  • 迭代节奏：模型与规则交替优化，避免单次调整带来不可控波动

3.4 高并发与稳定性保障​

并发控制

  • 接口限流：API 网关层基于 userId+IP 实现令牌桶限流（QPS=100/用户）
  • 资源隔离
    • 意图识别服务：线程池隔离（核心线程数=20，最大线程数=50）
    • Workflow 服务：流程实例隔离（不同业务线流程独立线程池）
  • 缓存策略
    • 会话上下文：Redis Cluster（过期时间=30min，主从复制+哨兵）
    • 高频规则/流程定义：本地 Caffeine 缓存（过期时间=5min，主动刷新）
  • 弹性伸缩：核心服务与模型服务分别独立扩缩，保障高峰稳定性

容错机制

  • 多级重试
    • LLM 调用：指数退避重试（最大重试次数=2，退避时间=1s/2s）
    • BC 端接口调用：固定间隔重试（最大重试次数=3，间隔=500ms）
  • 降级策略
    • LLM 服务降级：降级为规则引擎仅匹配高频意图
    • Workflow 引擎降级：核心流程降级为本地静态流程配置
  • 监控告警
    • 核心指标：意图识别准确率（<90% 告警）、人工转接率（>15% 告警）、接口响应时间（P95>500ms 告警）
    • 告警渠道：钉钉群 + 邮件，严重告警触发电话通知
  • 追踪链路：基于 TraceId 贯穿调用链，便于定位延时与失败节点

4. 核心链路​

4.1 全链路执行流程图​

5. 测试与验收标准​

5.1 功能测试​

  • 意图识别：测试集覆盖 100+意图（含高频/长尾），准确率 ≥92%
  • 固定流程：核心流程（发票 PDF 识别、订单查询）完成率 ≥99%，耗时 ≤3s
  • 反馈闭环：负样本沉淀量 ≥100/日，模型微调后准确率提升 ≥5%
  • 回归保障：每次模型/规则更新需通过核心意图回归测试

5.2 性能测试​

  • 并发能力：支持 1000 用户并发咨询，接口响应时间 P95≤500ms，P99≤1000ms
  • 稳定性：7×24 小时压测，服务可用性 ≥99.9%，无内存泄漏
  • 资源基线：峰值场景下 CPU 利用率 ≤70%，GPU 利用率可观测且可预警

5.3 验收指标​

指标验收标准
意图识别准确率≥92%
人工转接率≤15%
固定流程使用率≥30%
接口响应时间（P95）≤500ms
服务可用性≥99.9%